by Eric Goldman
This article describes some of the issues at play in structuring and
negotiating Web development and hosting agreements.
As a threshold issue, we must define our terms. Web
development and hosting relationships encompass a broad range of substantive
relationships, and it is crucial that the substantive relationships be kept
separate to ensure proper analysis.
Development can encompass a broad range of activities. Although rarely does a customer obtain only one of these services, the services can be broadly segregated into the following categories:
(a) File Conversion. The most basic service, this involves file manipulation such as converting non-HTML documents into HTML and scanning photos or graphics and saving such files into GIF or JPEG.
(b) Web Design. This
involves designing the look and feel of the website, including logos and
banners, navigation bars or tools, page layout and object placement.
(c) Code Development. This involves coding HTML pages (from
scratch), cgi scripts, Java applets or other applications.
(d) System Integration-Website Only. This involves integrating
the website with one or more third party applications, such as chat engines,
search engines, electronic commerce store fronts, and so on.
(e) System
Integration-Website and Back End Systems. This involves integrating the
website with one or more existing customer applications, such as legacy
systems.
The generic description "web hosting" can encompass a number of different relationships, such as:
(a) Collocation. Collocation occurs when the customer locates
customer-owned servers at the provider's facility. The provider is
"merely" responsible for connecting the servers to the Internet and
(usually) ensuring that the servers are up. In a straight collocation
relationship, the provider will not manipulate content on the servers. Providers
of these services usually provide space for the servers in chain-fenced
"cages." Collocators often offer additional services, such as
reselling equipment or software.
(b) Hosting. In a typical hosting relationship, the
provider (as opposed to the customer) provides the servers and software in
addition to the Internet connection. In some arrangements, the customer is
solely responsible for managing the content; in others, the provider may handle
some or all of the updates.
(c) Co-Branding. A popular technique has been to expand the
scope of a customer's website by co-branding pages on a third party's servers.
It is analytically appropriate to treat these co-branded pages as being hosted
by the third party.
(d) Outsourcing. Increasingly popular, outsourcing occurs
when a customer outsources one or more functions of its website to a third
party provider. By way of example, WhoWhere? allows a customer website to offer
co-branded email to its users by directing customer's users to co-branded pages
operated on WhoWhere?'s servers using WhoWhere?'s software. While outsourcing
is similar to co-branding, because the outsourcer is operating software for the
customer's (or its users') benefit, the customer is now also dependent on the
provider for the operation of this software.
Although not literally part of development or hosting, parties engaged in these businesses often offer additional services such as:
(a) Domain Name Registration. The provider will register
the customer's domain name with Internic (or others).
(b) Search Engine Registration. The provider will often
register the website URLs with the search engines to ensure that the pages are
indexed by the search engines.
(c) Online Promotion. The provider may engage in
promotional activities to promote the website or build the customer's online
image. This may include consulting on public relations on the Web, or perhaps
advising about integrating Internet promotions with
From the customer's perspective, website development is no
different from other types of development. Therefore, customers usually start
with their standard form of independent contractor agreement, of which most or
all applies.
Ownership
Within the parameters of a customer-favorable standard independent
contractor agreement, ownership tends to be the stickiest point. Customer's
usual starting point-that all development is a work-for-hire or otherwise owned
exclusively by customer-tends to be unreasonable in light of the actual manner
in which most web developers operate. Like other software developers, web
developers tend to recycle components and utilities from project to project.
Furthermore, for maintenance convenience, web developers find it beneficial to
have all of their clients use a uniform set of tools. Therefore, web developers
aggressively resist assigning ownership over certain aspects of their
development efforts to one particular customer, because this would prevent the
developer from recycling and standardizing.
Timing
Because the Web is constantly and quickly moving, customers often will
want to spell out a rigorous development schedule coupled with effective
remedies for failure to meet contracted milestones.
Platform Selection
The customer must make a few platform decisions prior to development
commencement. First, the customer must decide what platform the website will
reside on (i.e., Unix v. Windows). Second, the customer must decide if the
website will be optimized for a particular browser or will offer features that
cannot be accessed by certain browsers. If the customer decides to do so, the
customer will want to set up meaningfully rigorous acceptance tests to confirm
that the desired browsers can access the developed functionality.
Pricing and Updates
As with other development agreements, the developer wants to be paid
early, such as on a per-hour basis paid monthly or on a retainer basis.
However, the customer will want to defer as much payment as possible until
after acceptance. Unlike other development agreements, however, a website is
never "finished." Although there may be an initial "go
live" date, websites are living animals and will be constantly updated.
Therefore, customer will want to specify clearly what it is buying and how the
process of updating will be handled (and paid for). In particular, although
there usually will be interim updates to the website, it is typical for
websites to be completely overhauled, with respect to both look and feel and
organization, periodically (i.e., once a year or every 6 months). Therefore,
the parties should plan the development process and pricing for these
redesigns-and what triggers a payment to developer and what does not.
Conclusion about Web Development
As is typically the case, the customer usually has lots to say in a Web
development agreement, whereas usually the developer is happy to be silent on
many of these points. As a result, state of the art developer-favorable
agreements tend to be short-unacceptably short, from the customer's
perspective.
Service Levels
From the customer's perspective, the most crucial set of provisions
relate to the levels of service being provided. Unlike pure Internet service
provision agreements, where providers are grudgingly making some promises about
service availability (i.e., the service will be available 99% of the time, and
if there are excess outages, the customer will receive discounts or credits),
the state-of-the-art hosting provider-oriented agreements usually offer no such
service promises.
Usually this is unacceptable to customers. There are a large number of substantive standards that the customers would like to see met:
(a) Server Response and Time and Throughput Capacity. Slow
servers and inadequate throughput capacity of the Internet connection each mean
long waits for users, which results in frustrated users.
(b) Server Uptime. Server outages mean that the website is
completely offline. Therefore, customers want to see this minimized.
(c) System Redundancy. To reduce the possible effect of
server problems or force majeure (such as an outage by an upstream ISP), some
customers choose to require the provider to mirror servers or to connect
customer's servers via multiple ISPs.
(d) User Support. User support can be a tricky issue, because
a user inquiry could be technical (i.e., the following URL did not load
properly or my password does not work) or substantive (i.e., does the
cardigan sweater come in taupe?). Therefore, a process needs to be developed to
allocate responsibility for user inquiries. Furthermore, customer will want
standards for how provider deals with user inquiries that are provider's
responsibility, including professionalism in communicating, timeliness of
response and escalation procedures for user inquiries that provider cannot
solve quickly.
(e) Security. Depending on the system configuration and the
allocation of responsibilities between provider and customer, provider may not
have sole control over the security of the website. However, to the extent that
provider can control over security matters, customers will expect their
provider to do so. Usually this means proactively preventing security breaches
and laying out a process for fixing known security breaches once identified. At
minimum, customers usually expect providers to notify them when security
breaches or security holes are identified.
(f) Software Errors. To the extent that the host is also
responsible for site development, the customer will want standards regarding
how quickly provider must correct software or programming errors.
Rights in User Data
As Web-based business models become more refined, more customers are
realizing that data collected from or about its users are an increasingly
valuable asset. Therefore, customers need to take a number of steps to preserve
and maximize the value of this asset. Since provider's servers are collecting
information from or about users, customer's first step is to obtain copies of
the server logs applicable to its website. Most providers now provide raw
unprocessed server logs at no additional cost, but reports derived from the
server logs may have a separate price tag. In any event, it is crucial for
customers to get this data so they can learn more about their users.
Second, customer needs to treat all information about its
users as a trade secret. Not only is this crucial to restrict provider's
behavior, but it is also crucial to preserve a possible misappropriation suit
if some third party misappropriates user data (since if customer has not
protected the confidentiality of this information in all circumstances, it
cannot claim that such data is a trade secret).
If asked, collocators and hosts usually will designate
customer's user information as customer's trade secret, but co-branding or
outsource providers will often be less accommodating. Because user data has
such great potential value, trade secret license/"sharing" clauses
are becoming exponentially more complex and lengthy.
For customer, however, restricting any provider's use of
user data may be a bet-the-business proposition. If customer loses control of
this data, usually this will have ripple effects on customer's
business-potentially leaving customer's users exposed to spam or junk mail,
providing customer's competitors with a targeted list of potential customers
for its own goods or services, and educating customer's competitors and
customers (such as advertisers) about the true inner workings of customer's
website.
Provider's Post-Termination Duties
State-of-the-art provider-favorable agreements usually are silent about
what happens to the website after termination. However, from customer's
perspective, this may be another bet-the-business provision. If the website's
post-termination transition to a new provider is not handled properly, the
website will likely be off-line or error-prone for a period of time-frustrating
users and causing a loss of business.
Therefore, the customer wants to minimize the number of
circumstances by which the provider can unilaterally shut down the website or
otherwise stop performing under the agreement. Furthermore, the customer will
want to lay out a procedure, with time periods and effective remedies for
failure to meet the timeframes, for provider to transition the website to a new
provider and cooperate in all aspects of such transition. Ideally, customer
will have such transition procedures apply even if the customer is in breach of
the agreement.
To avoid the danger of a provider playing a hold-up game on
termination, customer can plan for transition by obtaining a complete copy of
the website periodically during the course of the relationship. Where feasible,
provider should deliver a complete copy very frequently (on the order of every
24 hours or less) so that a minimal amount of data would be lost if customer makes
a forced emergency transition.
On rare occasions, customers have gotten themselves into
trouble when the provider registered the website's domain name with Internic
and listed provider's employees as the administrative and technical contact
(instead of listing customer's employees). When this happens, Internic will
only respond to provider regarding changes the IP addresses of the website
servers, again permitting provider to play a hold-up game on termination.
Immediately following domain name registration, customer should check its
domain name registration to ensure that Internic will honor its request for
changes to the domain name records.
To the extent that the provider is also the website
developer, if customer does not obtain complete ownership of the website, then
customer needs to provide a license for the provider-owned components
post-termination.
Unauthorized Modifications
Customers will want to restrict provider from making unauthorized
modifications to the website (although, as described below, providers might
demand the right to make changes to minimize their liability). If providers are
given the right to make some modifications to the website, usually customer
will want an opportunity to review and approve these modifications before the
changes "go live."
Compliance with Laws
Particularly in the co-branding and outsourcing context, customers will
want to specify that provider will comply with all applicable laws.
Conclusion about Web Hosting Agreements
At their core, hosting agreements are like any other
services agreement, and therefore all of the usual rules of commercial
contracting apply. As is the case with development agreements, the service
provider will usually benefit from the default rules and therefore will be
silent on provisions in the agreement, while the customer will have a long list
of needed provisions.
While much of this article has focused on customer's wants
and needs, web hosts should address the possibility of their liability for
customer's (or its users') content. Historically, web hosts have feared that
they would be liable for customer content. Recently, the trend has been away
from host liability for customer content, but there remain some areas of
concern.
Defamation and Other "Publisher/Speaker" Torts
47 U.S.C. §230(c)(1) says: "No provider or user of an interactive
computer service shall be treated as the publisher or speaker of any
information provided by another information content provider." This
section should insulate web hosts from possible liability for any publisher or
speaker torts attributable to customer's content. A recent application of this
section was seen in Zeran v. America Online, 129 F.3d 327 (4th Cir.
1997), which held that AOL, as the host of a message board which contained
allegedly defamatory statements by a user, was not liable for any possible
defamation claim based on these statements (regardless of whether or not AOL
knew about the defamatory statements and failed to act reasonably in removing them).
While Zeran certainly is favorable to web hosts,
there remain a few points of ambiguity that could limit the benefits of Section
230(c)(1). First, we do not know the scope of torts deemed to be publisher or
speaker torts; while this appears to be a broad set of torts, we do not yet
know the boundaries. Second, the statute says that a "provider or user of
interactive computer services" is insulated from liability; no web host
yet has been determined to be a provider or user of an interactive computer
service for purposes of this statute, and the statutory definition was drafted
in a way that does not clearly include web hosts.
Obscenity/Child Pornography
Though there are no clear cases involving web host liability for
customer content that is obscene or child pornographic, web hosts may be
protected by Section 230(c)(1) described above. If not, web hosts are likely to
be protected at least as extensively as the bookseller was protected in Smith
v. California, 361 U.S. 147 (1959), which invalidated a statute imposing
strict liability for the distribution of obscenity as applied to a bookseller.
Copyright
Marobie-FL, Inc. v. National Association of Fire Equipment Distributors, 1997
WL 709747 (N.D. Ill. Nov. 13, 1997) is the only case that has squarely dealt
with web host liability for customer content. In Marobie, a customer infringed
third party copyrighted material, and the copyright owner sued both the
customer and the web host. The Marobie court found that the web host was not
liable for direct infringement, because it only provided the facilities for the
customer to commit copyright infringement, much like the provider of a public
copying machine would.
With respect to contributory copyright infringement, it was
unclear to the court whether the web host knew that any customer content was
copyrighted and the degree to which the web host "monitored, controlled,
or had the ability to monitor or control" the customer content. Therefore,
the court could not reach a summary judgement. The Marobie court ruled
that the web host was not vicariously liable for the copyright infringement,
because the web host charged a flat fee irrespective of the volume of
customer's content, and the web host did not receive any compensation that
depended on the number of visitors to the customer content.
The Marobie holding largely tracks what most practitioners
believed was the state of web host liability for copyright infringement since Religious
Technology Center v. Netcom On-Line Communication Services, Inc., 907 F.
Supp. 1361 (N.D. Cal. 1995), which held that Netcom, as the provider of access
to Usenet postings, was not liable for direct or vicarious copyright
infringement in a Usenet posting and was liable for contributory copyright
infringement only if Netcom knew or should have known of the copyright
infringement and failed to remove it within a reasonable period of time.
Several cases have followed the Netcom reasoning, including Sega Enterprises
Ltd. v. MAPHIA, 948 F. Supp. 923 (N.D. Cal. 1996) and Sega Enterprises
Ltd. v. Sabella, 1996 U.S. Dist. LEXIS 20470 (N.D. Cal. December 18, 1996).
However, the Marobie ruling leaves open several possible bases for web host liability, including:
(i) the web host knew that customer's
content was owned by a third party and web host failed to act in a reasonable
period of time;
(ii) the web host monitored, controlled, or had the ability to monitor or
control the customer content and failed to do so reasonably (note that this
factor is broader than was contemplated under Netcom); or
(iii) the web host was compensated in a way that gave it a direct financial
benefit from the copyright infringement.
Finally, although this line of reasoning was rejected by Marobie
and Netcom, there are a number of cases that have held system operators
directly liable for copyright infringement caused by users. See, e.g., Playboy
Enterprises, Inc. v. Frena, 839 F. Supp. 1552 (M.D. Fla. 1993); Central
Point Software, Inc. v. Nugent, 903 F. Supp. 1057 (E.D. Tex. 1995); Playboy
Enterprises, Inc. v. Webbworld, Inc., 1997 U.S. Dist. LEXIS 21264 (N.D.
Tex. December 11, 1997) (note that the Webbworld case is a bit confusing
because the system operator did more to process user content than system
operators normally perform). These cases hold significantly more peril for the
web host, because they would effectively hold the web host strictly liable for
copyright infringement in customer content.
Trademarks
Early cases such as the Frena case and Sega Enterprises Ltd. v.
MAPHIA, 857 F. Supp. 679 (N.D. Cal. 1994) seemed to indicate that system
operators might also be liable for trademark infringement caused by their
users.
While these cases were not thoroughly reasoned, a more
recent case still suggests that web hosts might be liable for contributory
trademark infringement. Lockheed Martin Corp. v. Network Solutions, Inc., 985
F. Supp. 949 (C.D. Cal. 1997) involved a claim by a trademark owner against NSI
for contributory trademark infringement for registering allegedly infringing
domain names. While the court held that NSI was not contributorily liable, the
court made several statements that suggested it might have analyzed web host
liability differently. For example, the court comments that "[w]here
domain name registration is necessary, the ISP usually acts as an agent to
secure and maintain registration." This type of statement implies that the
court might hold the ISP (or, in our situation, a web host) who registers a
domain name for a customer liable for contributory trademark infringement on an
agency theory.
In a web hosting agreement, providers should contractually
restrict customer from providing any content that is illegal or could create
liability for provider. Provider should also try to couple this restriction
with an indemnity for any suits based on customer content. While these
provisions are both helpful, there is always a risk that provider may be liable
and the indemnity may prove insufficient. Therefore, it is also a good idea for
providers to procure insurance for these types of risks; such insurance is
becoming increasingly available.
Finally, provider should retain in its contract the ability
to take any action it deems necessary or prudent (including without limitation
removing content) if provider believes that customer's (or customer's users')
content may create liability for provider.
Conclusion.
As repeatedly indicated, provider-favorable agreements tend
to operate largely by silence while customer-oriented agreements incorporate a
large number of substantive concerns. Empirically, this has proven true:
agreements provided by providers tend to be painfully short, and agreements
provided by customers tend to be egregious and oppressive. Perhaps this
article, by helping focus each party on reasonable compromises, will serve as a
catalyst towards reaching a more expeditious equilibrium in drafting Web
development and hosting agreements.
Eric Goldman (formerly Eric
Schlachter) is an attorney practicing cyberspace law with Cooley Godward LLP in
Palo Alto, California. He also is an adjunct professor of Cyberspace Law at
Santa Clara University School of Law. All cases cited in this article can be
found through the "Syllabus" on Mr. Goldman' personal home page,
located at http://eric_goldman.tripod.com.
Mr. Goldman can be reached at ericgoldman@onebox.com .